Groucho (Julius Henry) Marx
Robert Burton, The Anatomy of Melancholy
Franklin Delano Roosevelt
William Shakespeare
Jerome David Salinger
William Shakespeare
Alexander Pope, An Essay on Criticism
Insufficient memory to satisfy a new request, array subscript out of bounds, arithmetic overflow, division by zero, invalid function parameters.
a) Exception handling is designed to handle infrequently occurring situations that often result in program termination, so compiler writers are not required to implement exception handling to perform optimally.
b) Flow of control with conventional control structures is generally clearer and more efficient than with exceptions.
c) Problems can occur because the stack is unwound when an exception occurs and resources allocated prior to the exception may not be freed.
d) The "additional" exceptions can get in the way of genuine error-type exceptions. It becomes more difficult for the programmer to keep track of the larger number of exception cases. What does a catch(...) really catch?
It is unlikely that a library function will perform error processing that will meet the unique needs of all users.
An aborting program could leave a resource in a state in which other programs would not be able to acquire the resource.
The exception handlers (in the catch blocks) for that try block are skipped and the program resumes execution after the last catch block.
An exception thrown outside a try block causes a call to terminate.
The form catch(...) catches any type of error thrown in a try block. An advantage is that no thrown error can slip by. A disadvantage is that the catch has no parameter so it cannot reference information in the thrown object and cannot know the cause of the error.
This causes the search for a match to continue in the next enclosing try block. As this process continues, it may eventually be determined that there is no handler in the program that matches the type of the thrown object; in this case terminate is called, which by default calls abort. An alternate terminate function can be provided as an argument to set_terminate.
The first matching exception handler after the try block is executed.
This is a nice way to catch related types of exceptions.
Provide a single exception class and catch handler for a group of exceptions. As each exception occurs, the exception object can be created with different private data. The catch handler can examine this private data to distinguish the type of the exception.
void *.
A handler requiring standard conversions may appear before one with a precise match.
No, but it does terminate the block in which the exception is thrown.
The exception will be processed by a catch handler (if one exists) associated with the try block (if one exists) enclosing the catch handler that caused the exception.
It rethrows the exception.
Provide an exception specification listing the exception types that can be thrown from the function.
Function unexpected is called.
Through the process of stack unwinding, destructors are called for each of these objects.
If there is no information in the object that is required in the handler, a parameter name is not required in the handler.
Create a base class for all related exceptions. In the base class, derive all the related exception classes. Once the exception class hierarchy is created, exceptions from the hierarchy can be caught as the base class exception type or as one of the derived class exception types.
The solution to this exercise can be found on your Cyber Classroom CD. Copy the file cpphtp2/answers/P13_29.zip to your hard drive and unzip the program code.
The solution to this exercise can be found on your Cyber Classroom CD. Copy the file cpphtp2/answers/P13_31.zip to your hard drive and unzip the program code.
The solution to this exercise can be found on your Cyber Classroom CD. Copy the file cpphtp2/answers/P13_34.zip to your hard drive and unzip the program code.
The solution to this exercise can be found on your Cyber Classroom CD. Copy the file cpphtp2/answers/P13_40.zip to your hard drive and unzip the program code.
The solution to this exercise can be found on your Cyber Classroom CD. Copy the file cpphtp2/answers/P13_42.zip to your hard drive and unzip the program code.
13.1
13.2
13.3
13.4
13.5
13.6
13.7
13.9
13.10
13.11
13.12
13.13
13.14
13.15
13.16
13.17
Figures
In this chapter, we introduce exception handling. The extensibility of C++ can increase substantially the number and kinds of errors that can occur. The features presented here enable programmers to write clearer, more robust, more fault-tolerant programs. Recent systems developed with these and/or similar techniques have reported positive results. We also mention when exception handling should not be used.
Exception handling is typically used in situations in
which the error will be dealt with by a different part of
the program (i.e., a different scope) from that which
detected the error. A program that carries on an
interactive dialog with a user should not use exceptions
to process input errors.
There is another reason to avoid using exception
handling techniques for conventional program control.
Exception handling is designed for error processing
which is an infrequent activity that is often used
because a program is about to terminate. Given this, it
is not required that C++ compiler writers implement
exception handling for the kind of 
optimal performance
that might be expected of regular application code.Standardization is especially
important on large software projects where dozens or
even hundreds of people work on separate components
of a system and these components need to interact for
the overall system to function properly.Exception handling should be used to process only
exceptional situations, despite the fact that there is
nothing to prevent the programmer from using
exceptions as an alternate for program control; to
process exceptions for program components that are not
geared to handling those exceptions directly; to process
exceptions from software components such as
functions, libraries, and classes that are likely to be
widely used, and where it does not make sense for those
components to handle their own exceptions; on large We have presented a variety of ways of dealing with exceptional situations prior to this chapter. The following summarizes these and other useful techniques.
Resource issues are also
important here. If a program obtains a resource, the program should normally return that resource before program termination. C++ exception handling is geared to situations in which the function that detects an error is unable to deal with it. Such a function will throw an exception. There is no guarantee that there will be "anything out there"--i.e., an exception handler specifically geared to processing that kind of exception. If there is, the exception will be caught and handled. If there is no exception handler for that particular kind of exception, the program terminates.
The exception is thrown in a try block in the function,
or the exception is thrown from a function called
directly or indirectly from the try block. The point at Now let us consider a simple example of exception handling. The program of
Fig. 13.1 uses try, throw and
catch to detect a division by zero, indicate a divide-by-
zero exception and handle a divide-by-zero exception.Fig. 13.1, the catch block specifies that it
will catch exception objects of type
DivideByZeroException; this type matches the type of
the object thrown in function quotient. The body of this
exception handler issues an error message and returns,
in this case with 1 indicating termination because of an
error. Exception handlers can be much more elaborate
than this. Fig. 13.1 a return statement is
executed that returns 0, indicating normal termination.object is received in the parameter specified in the
catch handler (in this case, parameter error), and the
message is printed there through a call to public access
function printMessage. The throw keyword is used to indicate that an exception has occurred. This is called throwing an exception. A throw normally specifies one operand (a special case we will discuss specifies no operands). The operand of a throw can be of any type. If the operand is an
object, we call it an exception object. A conditional
expression can be thrown instead of an object. It is
possible to throw objects not intended for error
handling.As part of throwing an exception, a temporary copy of
the throw operand is created and initialized. This
temporary object then initializes the parameter in the
exception handler. The temporary object is destroyed
when the exception handler completes execution and
exits.Although an exception can terminate program
execution, it is not required to terminate program
execution. However, an exception does terminate the
block in which the exception occurred.Exception handlers are contained in catch blocks. Each catch block starts with the keyword catch followed by parentheses containing a type (indicating the type of exception this catch block handles) and an optional parameter name. This is followed by braces delineating the exception-handling code. When an exception is caught, the code in the catch block is executed.
specifies in parentheses the type of the object to be
caught. The parameter in a catch handler can be named
or unnamed. If the parameter is named, the parameter An exception that is not caught causes a call to
terminate which by default terminates a program by
calling abort. It is possible to specify customized
behavior by designating another function to be executed
by providing that function's name as the argument in a
set_terminate function call.A catch followed by parentheses enclosing an ellipsis catch( ... )means to catch all exceptions.
order of the
handlers will affect the manner in which the exception
is handled.Second, because of
inheritance hierarchies, it is possible that a derived-
class object can be caught either by a handler specifying the handler parameter is of a base-class pointer or
reference type and the thrown object is of a derived-
class pointer or reference type.A try block followed by several catches resembles a
switch statement. It is not necessary to use break to
exit an exception handler in a manner that skips over
the remaining exception handlers. Each catch block They could look at the situation causing the error,
remove the cause of the error and retry by calling the
original function that caused an exception (this would It is not possible to return to the throw point by issuing
a return statement in a catch handler. Such a return
simply returns to the function that called the function
containing the catch block.Such an exception will not be processed
by catch handlers associated with the same try block as
the catch handler throwing the exception. Rather the
thrown exception will be caught, if possible, by a catch
handler associated with the next outer try block.It is possible that the handler that catches an exception may decide that it cannot process the exception or it may simply want to release resources before letting someone else handle it. In this case, the handler can simply rethrow the exception with the statement
throw;
Such a throw with no arguments rethrows the
exception. If no exception was thrown to begin with,
then the rethrow causes a call to terminate. Even if a handler can process an exception, and
regardless of whether it does any processing on that Fig. 13.2 demonstrates rethrowing an
exception. In the try block at line 26 of main, function
throwException is called. In the try block of function
throwException, the throw statement at line 13
throws an instance of standard library class exception
(defined in header file <exception>). This exception is
caught immediately in the catch handler at line 15
which prints an error message then rethrows the An exception specification enables a list of exceptions that can be thrown by a function to be specified.
int g( float h ) throw ( a, b, c )It is possible to restrict the exception types thrown from a function. The exception types are specified in the function declaration as an exception specification (also called a throw list). The exception specification lists the exceptions that may be thrown. A function may throw the indicated exceptions or derived types.{
// function body
}
exception; this, too, would generate a
call to unexpected.void g(); // this function can throw any exception
Function unexpected calls the function specified with the set_unexpected function. If no function has been specified in this manner, terminate is called by default.
When an exception is thrown but not caught in a particular scope, the function-call stack is unwound and an attempt is made to catch the exception in the next outer try/catch block. Unwinding the function-call stack means that the function in which the exception was not caught terminates, all local variables in that function are destroyed and control returns to the point at which that function was called. If that point in the program is in a try block, an attempt is made to catch the exception. If that point in the program is not in a try block or the exception is not caught, stack unwinding
Fig. 13.3 demonstrates stack unwinding.First, let us deal with an issue we have mentioned, but that has yet to be satisfactorily resolved. What happens when an error is detected in a constructor? For example, how should a String constructor respond when new fails and indicates that it was unable to obtain the space needed to hold the String's internal representation? The problem is that a constructor cannot return a value, so how do we let the outside world know that the object has not been properly constructed? One scheme was simply to return the improperly constructed object and
Various exception classes can be derived from a common
base class. If a catch catches a pointer or
reference to an exception object of a base-class type, it
can also catch a pointer or reference to all objects of
classes derived from that base class. This can allow for
polymorphic processing of related errors.There are several methods of dealing with new failures. To this point, we have used macro assert to test the value returned from new. If that value is 0, the assert macro terminates the program. This is not a robust mechanism for dealing with new failures--it does not allow us to recover from the failure in any way. The ANSI/ISO C++ draft standard specifies that when new fails, it throws a bad_alloc exception (defined in header file <new>). However, many compilers are not current with the draft standard and still use the version of new that returns 0 on failure. In this section we
Figure 13.4 demonstrates new returning 0 on failure to
allocate the requested amount of memory. The for Figure 13.5 demonstrates new throwing bad_alloc
when it fails to allocate the requested memory. The for
structure at line 12 inside the try block is supposed to
loop 10 times and on each pass allocate an array of
5,000,000 double values (i.e., 40,000,000 bytes
because a double is normally 8 bytes). If new fails and
throws a bad_alloc exception, the loop terminates and
the program continues in the exception-handling flow
of control at line 18 where the exception is caught and
processed. The message "Exception occurred: " is
printed followed by exception.what() which returns a
string with an exception-specific message ("Allocation
Failure" in the case of bad_alloc). The output shows The ANSI/ISO C++ draft standard specifies that
standard-compliant compilers can still use a version of
new that returns 0 when it fails. For this purpose, the
header file <new> defines the type nothrow that is
used as follows:double *ptr = new( nothrow ) double[ 5000000 ];The preceding statement indicates that the version of new that does not throw bad_alloc exceptions (i.e., nothrow) should be used to allocate an array of 5,000,000 double values.
2. Throw an exception of type bad_alloc.
3. Call function abort or exit (both from header file <cstdlib> or <stdlib.h>) to terminate the program.
The program of
Fig. 13.6 demonstrates
set_new_handler. The function customNewHandler
simply prints an error message and terminates the
program with a call to abort. The output shows that
only three iterations of the loop were performed before
new failed and threw the bad_alloc exception. The
output on your system may differ based on the physical A common programming practice is to allocate dynamic memory (possibly an object) on the free store, assign the address of that memory to a pointer, use the pointer to manipulate the memory and deallocate the memory with delete when the memory is no longer needed. If an exception occurs after the memory has been allocated and before the delete statement is executed, a memory leak could occur. The ANSI/ISO C++ draft standard provides class template auto_ptr in header file <memory> to deal with this situation.
Figure 13.7
demonstrates an auto_ptr object that points to an object
of class Integer (defined at lines 818). auto_ptr< Integer > ptrToInteger( new Integer( 7 ) );
ptrToInteger->setInteger( 99 );uses the auto_ptr overloaded -> operator and the function call operator () to call function setInteger on the Integer object pointed to by ptrToInteger.
( *ptrToInteger ).getInteger()in line 30 uses the auto_ptr overloaded * operator to dereference ptrToInteger then uses the dot (.) operator
Experience has shown that exceptions fall nicely into a number of categories. The C++ draft standard includes a hi
erarchy of exception classes. This hierarchy is
headed by base class exception (defined in header file
<exception>) which offers the service what() that is
overridden in each derived class to issue an appropriate
error message.Also derived from exception are the exceptions thrown
by C++ language features--for example, bad_alloc is
thrown by new (Section 13.14), bad_cast is thrown by
dynamic_cast (Chapter 21) and bad_typeid is thrown
by typeid (Chapter 21). By including
std::bad_exception in the throw list of a function, if
an unexpected exception occurs, unexpected() will
throw bad_exception instead of terminating (by
default) or instead of calling another function specified
with set_unexpected.that an arithmetic underflow error occurred. abort
assert macro
auto_ptr
B
bad_alloc exception
bad_cast
bad_typeid
C
catch all exceptions
catch an exception
catch( ... )
D
dynamic_cast
E
empty exception specification
empty throw statement
enclosing try block
exception
exception object
exception specification
exit
F
fault tolerance
H
handler
I
invalid_argument
L
length_error
M
<memory>
mission critical
N
nested scope
<new>
new_handler
nothrow
O
out_of_range
overflow_error
R
runtime_error
S
set_new_handler
set_terminate
set_unexpected
stack unwinding
std::bad_exception
<stdexcept>
terminate
throw an exception
throw expression
throw list
throw point
throw with no arguments
throw()
try block
U
unexpected()
Fig. 13.2 Rethrowing an exception.
Fig. 13.3 Demonstration of stack unwinding.
Fig. 13.4 Demonstrating new returning 0 on failure.
Fig. 13.5 Demonstrating new throwing bad_alloc on failure.
Fig. 13.6 Demonstrating set_new_handler.
Fig. 13.7 Demonstrating auto_ptr.
List five common examples of exceptions.
Give several reasons why exception-handling techniques should not be used for conventional program control.
Why are exceptions appropriate for dealing with errors produced by library functions?
What is a "resource leak?"
If no exceptions are thrown in a try block, where does control proceed to after the try block completes execution?
What happens if an exception is thrown outside a try block?
Give a key advantage and a key disadvantage of using catch(...).
What happens if no catch handler matches the type of a thrown object?
What happens if several handlers match the type of the thrown object?
Why would a programmer specify a base-class type as the type of a catch handler and then throw objects of derived-class types?
How might a catch handler be written to process related types of errors without using inheritance among exception classes?
What pointer type is used in a catch handler to catch any exception of any pointer type?
Suppose a catch handler with a precise match to an exception object type is available. Under what circumstances might a different handler be executed for exception objects of that type?
Must throwing an exception cause program termination?
What happens when a catch handler throws an exception?
What does the statement throw; do?
How does the programmer restrict the exception types that can be thrown from a function?
What happens if a function does throw an exception of a type not allowed by the exception specification for the function?
What happens to the automatic objects that have been constructed in a try block when that block throws an exception?
List the various exceptional conditions that have occurred in programs throughout this text. List as many additional exceptional conditions as you can. For each of these, describe briefly how a program would typically handle the exception using the exception-handling techniques discussed in this chapter. Some typical exceptions are: Division by zero, arithmetic overflow, array subscript out of bounds, exhaustion of the free store, etc.
Under what circumstances would the programmer not provide a parameter name when defining the type of the object that will be caught by a handler?
A program contains the statement
throw;Where would you normally expect to find such a statement? What if that statement appeared in a different part of a program?
Under what circumstances would you use the following statement?
catch(...) { throw; }
Compare and contrast exception handling with the various other error- processing schemes discussed in the text.
List the benefits of exception handling over conventional means of error processing.
Provide reasons why exceptions should not be used as an alternate form of program control.
Describe a technique for handling related exceptions.
Until this chapter, we have found that dealing with errors detected by constructors is a bit awkward. Exception handling gives us a much better means of dealing with such errors. Consider a constructor for a String class. The constructor uses new to obtain space from the free store. Suppose new fails. Show how you would deal with this without exception handling. Discuss the key issues. Show how you would deal with such memory exhaustion with exception handling. Explain why the exception handling method is superior.
Suppose a program throws an exception and the appropriate exception handler begins executing. Now suppose that the exception handler itself throws the same exception. Does this create an infinite recursion? Write a C++ program to check your observation.
Use inheritance to create a base exception class and various derived exception classes. Then show that a catch handler specifying the base class can catch derived-class exceptions.
Show a conditional expression that returns either a double or an int. Provide an int catch handler and a double catch handler. Show that only the double catch handler executes regardless of whether the int or the double is returned.
Write a C++ program designed to generate and handle a memory exhaustion error. Your program should loop on a request to create dynamic storage through operator new.
Write a C++ program which shows that all destructors for objects constructed in a block are called before an exception is thrown from that block.
Write a C++ program which shows that member object destructors are called for only those member objects that were constructed before an exception occurred.
Write a C++ program that demonstrates how any exception is caught with catch(...).
Write a C++ program which shows that the order of exception handlers is important. The first matching handler is the one that executes. Compile and run your program two different ways to show that two different handlers execute with two different effects.
Write a C++ program that shows a constructor passing information about constructor failure to an exception handler after a try block.
Write a C++ program that uses a multiple inheritance hierarchy of exception classes to create a situation in which the order of exception handlers matters.
Using setjmp/longjmp, a program can transfer control immediately to an error routine from a deeply nested function invocation. Unfortunately, as the stack is unwound, destructors are not called for the automatic objects that were created during the sequence of nested function calls. Write a C++ program which demonstrates that these destructors are, in fact, not called.
Write a C++ program that illustrates rethrowing an exception.
Write a C++ program that uses set_unexpected to set a user-defined function for unexpected, uses set_unexpected again, and then resets unexpected back to its previous function. Write a similar program to test set_terminate and terminate.
Write a C++ program which shows that a function with its own try block does not have to catch every possible error generated within the try. Some exceptions can slip through to, and be handled in, outer scopes.
Write a C++ program that throws an error from a deeply nested function call and still has the catch handler following the try block enclosing the call chain catch the exception.